home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1995 October / EnigmA AMIGA RUN 01 (1995)(G.R. Edizioni)(IT)[!][issue 1995-10][Aminet 7].iso / Aminet / comm / fido / SHELTER275.lha / XPRS / xprslk.doc < prev    next >
Text File  |  1994-11-29  |  7KB  |  138 lines
  1.  
  2.     xprslk.library
  3.     Robert Williamson
  4.  
  5.     This library is an implementation of the SEAlink protocol
  6.     SEAlink is (C) COPYRIGHT 1986,87 by System Enhancement Associates, Inc.
  7.     
  8.      xprslk.library implements the SeaLink protocol for EMSI sessions, term
  9. programs and BBSs.  SEAlink is a sliding window protocol with overdrive and
  10. resync  options.   The  following is a description of that protocol derived
  11. form FTS-007, FSC-0010 and FSC-0018.
  12.  
  13.      The intent of SEAlink is to provide a file transfer protocol that does
  14. not  suffer  from  propagation  delays, such as are introduced by satellite
  15. relays  or  packet switched networks.  Actual tests have shown that SEAlink
  16. is  capable  of  virtually  eliminating  propagation  delays and turnaround
  17. delays.   File transfers which normally suffer a degradation of 50% or more
  18. due  to  satellite  relays,  proceed  as  fast  as  local  transfers.  Even
  19. transfers  within  the  local  exchange are speeded up by up to 20% at 2400
  20. baud by the elimination of turnaround delays.  Large volume tests show that
  21. SEAlink  is  capable of coming to within 2% of the theoretical minimum time
  22. for data transfer.
  23.  
  24.     SEAlink  adds  a  block  number  to  the  ACK  and  NAK used in XMODEM.
  25. XMODEM/CRC  uses  a  "C" in place of a NAK to indicate CRC error detection.
  26. SEAlink  follows this convention, and supports either checksum or CRC.  For
  27. brevity, this document will use the term NAK to mean either a true NAK (hex
  28. 15) or a C (hex 43).
  29.  
  30.      From  the  receiver's  point  of  view,  it  does  not  matter  if the
  31. transmitter  is using sliding window or not.  The receiver simply sends ACK
  32. and  NAK  packets  as  appropriate.   Any XMODEM driver tested to date will
  33. simply ignore this excess data behind the ACK or NAK.
  34.  
  35.      From  the  transmitter's  point of view, it just barely matters if the
  36. receiver  can  handle sliding window.  The transmitter always acts as if it
  37. is  sending  sliding  window,  but varies the window size.  If it is seeing
  38. valid  block numbers and check values behind the received ACKs and NAKs, it
  39. sets  the window size to six blocks.  Otherwise, it sets the window size to
  40. one  block.   The  result is that it only "sends ahead" if the receiver can
  41. handle it.
  42.  
  43.      SEAlink  is also capable of passing system dependent information, such
  44. as  true file size and time of last modification.  This data is passed in a
  45. special header block.  The header block looks exactly like any other block,
  46. except  that  it  is  block  number  zero.   Protocol  capbilities are also
  47. indicated in this block.
  48.     
  49.      Of special interest is the byte flag at offset 40 in block zero.  This
  50. is  the  "Overdrive  flag",  and  is  used  to  trigger  streaming mode for
  51. high-speed,  half  duplex  modems.   In  Overdrive  mode the receiver stops
  52. sending ACKs for the bulk of the file transfer, thus facilitating transfers
  53. over  a  half-duplex  connection.   Overdrive is never required over a full
  54. duplex  connection.   Overdrive requires that the basic link be effectively
  55. error  free.   Overdrive  is  disengaged  aotomatically  if  either  of the
  56. following conditions are encountered.
  57.     The  transmitter  will  disengaged  overdrive  if  it  detects that the
  58. receiver has dropped out of overdrive, or does not support overdrive.
  59.     The  receiver  will disengage overdrive if it finds itself receiving an
  60. excessive number of bad blocks, as Overdrive requires an error-free link.
  61.  
  62.     Another  byte in block 0 indicates the Resync protocol enhancement that
  63. allows the protocol to pickup broken transfers were it was interrupted.  As
  64. a side effect transmissions of exact duplicate files (from whatever source)
  65. will only result in the two systems exchanging EOT and thus saving a lot of
  66. transfertime and costs.
  67.  
  68.      Any  field  which  the transmitter cannot support should be set to all
  69. zeros.   Conversly,  the  receiver  should  ignore  any  null  fields.  The
  70. receiver may ignore any field which he cannot support.
  71.  
  72.     The  number  of  blocks in the sliding window is set depending upon the
  73. baud  rate,  with  a  minimum  of 6 (768 bytes) and a maximum of 127 (16256
  74. bytes). When OverDrive is enabled, the window is the size of the file being
  75. sent.
  76.     If  more  than 10 ACKS are received during a session, it is assumed that
  77. the remote does not support OverDrive and it is disabled.
  78.     If more than 10 NAKS are received during a window, the slide is reduced
  79. to 1 block.
  80.  
  81.  
  82.     XPR options:
  83.  
  84.     B       - allow use of long filenames (32 chars)
  85.               this uses the mailer field of the Sealink header  
  86.     O       - OverDrive, receiver does not ACK
  87.     R       - allow ReSync (resume)
  88.     L<bps>  - Link rate
  89.  
  90.     Defaults: BN,OY,RN,L0
  91.  
  92.  
  93.  
  94. wpl concerns:
  95.     If  used  with  a  mailer  written in the WPL language, the name of the
  96. transmitting  program in the SeaLink header will be set to the value of the
  97. WPL variable "$(host.mailer)".  Otherwise, the transmitting program name is
  98. set to "XPRslk".
  99.  
  100.     XprSetup  does  not  read  any  variables,  so you must set option L to
  101. $(baud)  so  that  all calculations are based upon the actual link rate and
  102. not the locked rate.
  103.  
  104.    XprSetup makes an XPR library ready for a transfer.  The first parameter
  105. given  is the xpr library name, and the second parameter is a string passed
  106. to  the xpr library with XProtocolSetup().  The variable $(XprSetup) is set
  107. to  the  numeric  return  of  XProtocolSetup().   A  value of 0 indicates a
  108. failure, otherwise the setup was successful.
  109.  
  110.    Return Values in $(Setup) are or'ed from the following:
  111.  
  112.         XPRS_FAILURE    0x00000000L 
  113.         XPRS_SUCCESS    0x00000001L
  114.         XPRS_NORECREQ   0x00000002L
  115.         XPRS_NOSNDREQ   0x00000004L
  116.         XPRS_HOSTMON    0x00000008L
  117.         XPRS_USERMON    0x00000010L
  118.         XPRS_HOSTNOWAIT 0x00000020L
  119.         XPRS_NOUPDATE   0x00008000L
  120.         XPRS_XPR2001    0x00010000L *
  121.         XPRS_DOUBLE     0x00020000L *
  122.  
  123.     *  Note:  private jammail versions of wpl.library require both returned
  124. to  enable  dual-status  display.  This is WRONG.  Only XPRS_XPR2001 should
  125. trigger  use  of  dual-status  display.   Therefore support for dual-status
  126. display,  while  in  the sources, is disabled via a compile define for this
  127. release.
  128.  
  129.     WARNINGS:
  130.     This is most certainly a BETA release.
  131.     Presently  ReSync  is  not enabled, turning it on will result in failed
  132. sessions.
  133.     OverDrive does not check all possible error conditions as yet. Strange
  134. results are encountered depending upon what program the remote is running
  135. and/or how the remote has setup his options.
  136.  
  137.  
  138.